Skip to content

Bugfix + features for lessening forwarding load - #153

Merged
ssahani merged 4 commits into
systemd:mainfrom
derobert:feature/forwarding-load-control
Oct 17, 2026
Merged

ssahani merged 4 commits into
systemd:mainfrom
derobert:feature/forwarding-load-control

Conversation

@derobert

Copy link
Copy Markdown
Contributor

Summary

Adds two features to help reduce load on the forwarding destinations:

  • Exclude a list of systemd units (joining the existing options for syslog priorities and facilities)
  • Chunk large journal sends and delay between chunks. This also fixes problems when the large send is very large (e.g., first start) where previously the send wouldn't always complete before watchdog timeout.

First commit is a fix for #149.

Changes

  • Tiny fix for Refactor in 57b0864a4577f880bb9f2bdef89868f7fcef96c5 drops all log messages #149.
  • Add new option ExcludeUnits, which is a space-separated list of systemd unit names to exclude from forwarding. Note I implemented this expecting a short list — presumably just the one or two that are producing a lot of noise. That keeps the code simple, but performance will suffer if someone tries to list hundreds. Default to not exclude any.
  • Add a new option ChunkMaxLineCount, default 100. This controls the maximum number of journal lines that'll be handled in the tight read-send loop. After that many lines, it'll save the state file, and use sd_event_add_time to pause for a bit (configurable by ChunkDelaySec)
  • Add ChunkDelaySec, the delay for above

Note that the previous behavior without the chunking was quite bad if you installed netlogd with a substantial existing journal (which you want to send). It'd try to send the whole thing, which could be many millions of lines, in that loop. Since it wasn't returning to the main event loop, the systemd watchdog didn't get notified — so systemd would eventually kill it. And also since it wasn't returning, the state file wasn't updated with the new cursor position. So if you restarted it, it'd start over from the beginning. The chunking fixes that.

The default are just numbers I picked; I guessed 100 lines + one second is probably high enough that it won't happen, except during the initial send after installation. And if it does happen, very few installs would be unable to keep up because of the delay.

It might be possible to lower the watchdog timeout with this.

Testing

  • meson test -C build passes
  • Tested with UDP/TCP/TLS as applicable (Tested forwarding to Alien Vault, rfc5425 + tls)
  • N/A New code has test coverage (if applicable) Didn't seem applicable, as there aren't tests that section of the codebase

Checklist

  • Code follows systemd coding style (I did my best, happy to fix anything I missed)
  • Commit messages are clear and descriptive
  • Documentation updated (if applicable)
  • No new compiler warnings

Looks like the refactor in 57b0864
caused all messages to be discarded by making parse_journal_fields
return 0 on success, but then also skipping the message when it does in
journal_read_input. This looks to get it working again.
Add a new config option to exclude systemd units from log forwarding.
Note this is intended for a small number of units, not hundreds, so it's
just a linearly compared list not anything more fancy.
Add two new options to pause when we've just sent X lines in a tight
loop (a "chunk"). This allows the cursor to be updated on disk, send the
systemd watchdog notification/ping, and avoid overloading the receiver on
first start (where we may be trying to transmit millions of historical
log lines).

Better show the status in systemctl status. Previously would often just
show "idle". Now should say if its ready, idle (disconnected), or paused
(inter-chunk delay).

Documentation included.
Sorry about that, I missed one spot when I changed the 10s I was testing
with to 1s. Was just the example config, but that'd be confusing, so
fixing.
@ssahani
ssahani merged commit cdb94c3 into systemd:main Oct 17, 2026
8 checks passed
@derobert
derobert deleted the feature/forwarding-load-control branch October 22, 2026 15:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants